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MKTHOD AND SYSTEM FOR EXCHANGE OF MULTICALL CAPABILITIES 
BETWEEN TERMINAL AND NETWORK 

RELATED APPLICATION 

5 This application is related to, and claims priority from, U.S. Provisional Patent 

Application Serial No. 60/174,908, entitled "Exchange of Multicall Capabilities between 
UE and CN in UMTS", filed on January 10, 2000, the disclosure of which is 
incorporated here by reference. 

10 BACKGROUND 

The present invention relates to handling and signaling associated with multicall 
capability in radiocommunication systems. 

Radiocommunication standards and systems continue to evolve at a fast pace in 
recent years. The so-called third generation networks are among the latest developments 

15 in this sector, one example of which is referred to as the Universal Mobile 

Telecommunication Systems (UMTS). These third generation networks enable 
subscribers to set up a variety of different user services, e.g., multimedia services, 
speech calls, data calls, fax calls, short messages, etc. Among other capabilities, third 
generation systems allow a subscriber to set up more than one call simultaneously, 

20 providing an individual radio bearer for each of the calls. This feature is called 
"Multicall" in UMTS specifications. 

The Multicall feature enables a subscriber in a UMTS system to have, for 
instance, a speech connection while sending a fax, browsing the Internet, or performing 
data transmissions of any kind. Furthermore, the feature provides the capability to 

25 increase the bandwidth for a certain type of connection beyond the limit given by a 

single bearer. This is done by performing an inverse multiplexing scheme to aggregate 
the bandwidth of several calls. For readers interested in more detail regarding the 
multicall feature in general, an exemplary explanation can be found in the 3GPP 
specification 3G TS 22.135 Version 3.0.0, published October 1999, the disclosure of 

30 which is incorporated here by reference. 
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The Multicall feature interacts with other features specified in the UMTS 
standard, e.g., the supplementary services referred to as Call Waiting and Call Hold. 
The Call Waiting service permits a mobile subscriber to be notified of an incoming call 
while no other bearer is available to support the incoming call and the mobile subscriber 
5 is already engaged in at least one active or held call. Upon notification, the subscriber 
can either accept, reject, or ignore the incoming call. 

The Call Hold service allows a served mobile subscriber, who is provisioned 
with this Supplementary Service, to interrupt communication on an existing active call 
and then subsequently, if desired, re-establish communication. The radio bearer remains 

10 assigned to the mobile subscriber after the communication is interrupted to allow the 
origination or possible termination of other calls. Consider the following interactions 
between the Multicall, Call Waiting and Call Hold features. 

For a Multicall subscriber, the Call Waiting service is invoked when all bearers 
available for a certain subscriber are in use and an incoming call is received by the 

15 serving network entity or if a speech call is offered and another speech call is already 
ongoing for that subscriber. The serving network entity can, for example, be a Mobile 
services Switching Centre / Visitor Location Register (MSC/VLR) that performs the call 
control and requests the establishment of a call bearer for the subscriber. The number of 
available bearers depends on the maximum limit of bearers as defined in the Multicall 

20 subscription, the capabilities of the serving network entity, and the capabilities of the 
terminal. 

For a Multicall subscriber, the Call Hold service is implicitly invoked when all 
bearers available for a certain subscriber are in use, one of the established calls is a 
speech call, and the subscriber wants to set up or accept a new call. This procedure is 

25 well known to those skilled in the art, for example as described in the 3GPP 

specification TS 22.030 Version 3.0.1, published October 1999, the disclosure of which 
is also incorporated here by reference. When this occurs, the speech call is put on hold, 
and the new call will use the bearer formerly used by the speech call. The number of 
available bearers in this context depends on the maximum limit of bearers as defined by 

30 limits set by the operator, limits set by the user, the capabilities of the serving network 



027559-039 



-3- 

entities, and the capabilities of the terminal. In addition to the MSC/VLR mentioned 
above, the capabilities of the serving network in connection with the number of bearers 
available may also be limited by other nodes, e.g, the Radio Network Controller (RNC). 
However, currently no mechanism exists to detect the actual limit for the number 
5 of bearers available to a Multicall subscriber. This shortcoming prevents backward 
compatible service behavior for second generation networks, e.g., GSM networks. The 
actual limit is the lowest number of bearers supported by the terminal, the network, the 
operator setting and the user setting. The number of bearers supported by the terminal, 
the network, the operator setting and the user setting may differ. This can cause a 

10 number of problems in the handling of calls made by GSM and/or UMTS equipment, 
particularly in hybrid GSM/UMTS equipment. 

For example, if the maximum number of bearers supported by the terminal is 
higher than the maximum number of bearers supported by the serving network entity, 
the following problems can occur. Consider that, for a particular call incoming to the 

15 terminal, the serving network entity detects that the maximum number of bearers 
allowed by the multicall subscription of the called subscriber is already used. The 
serving network entity will then invoke the Call Waiting service. The call is then 
offered as a waiting call to the terminal. However, since the maximum number of 
bearers from the terminal point of view is not yet reached, it may request the serving 

20 network entity to allocate a new bearer for the waiting call, which bearer is not 
available. 

Likewise, for calls which are to be setup from the terminal, this imbalance 
between the number of bearers available for the terminal versus the number of bearers 
available for the serving network entity can cause difficulties. Since the terminal 

25 perceives that at least one radio bearer is available for it to set up an outgoing call, the 
terminal does not implicitly invoke the Call Hold service for its ongoing Speech call 
prior to attempting call setup. In response to the call setup signalling, the network will 
detect that there is no bearer available. Since the speech call is not on hold, the serving 
network entity cannot re-use the bearer allocated for the speech call for the new call. 

30 The serving network entity will then reject the call set-up. 
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Problems may also occur for the reverse discrepancy, i.e., in the case that the 
maximum number of bearers supported by the terminal is lower than the number of 
bearers that can be offered by the network. When the serving network entity tries to set 
up a call to a terminal that is using all of its available bearers, it may not invoke the Call 
5 Waiting feature since, from the serving network entity's perspective, there is an 

available radio bearer to set up the call. Instead, the terminal may reject the call and the 
waiting call will not be offered to the subscriber. 

Accordingly, it would be desirable to provide systems and methods for handling 
the exchange of multicall capabilities in a manner which permitted Call Waiting and Call 
10 Hold to be performed in a manner that supports backward compatibility with second 
generation devices and handles potential imbalances between the number of bearers 
available for setting up calls between different nodes of radiocommunication systems. 

SUMMARY 

15 These and other drawbacks, problems and limitations of conventional 

radiocommunication systems are overcome according to the present invention. 

It is object of the invention to provide a mechanism for the exchange of 
information regarding multicall capabilities. 

It is a further object of the invention to provide a mechanism to determine the 
20 actual limit on the number of bearers available between a particular device and the 
network at a given time. 

It is another object to use the actual limit on the number of bearers in order to 
ensure that the service interactions as seen by the user are backward compatible with 
second generation systems. 
25 The involved system entities include the terminal, the serving network entity and 

the entity handling the radio resources. 

This limit information can take a number of forms and vary according to 
exemplary embodiments of the present invention. For example, limit information 
associated with an involved system entity can be, for example, either at least one 
30 informational parameter available at the system entity regarding factors limiting the 
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number of available bearers or an informational parameter available at the system 
entities regarding a most limiting factor. 

The bearer limiting factors associated with terminal devices are, for example, 
introduced by the manufacturer of the terminal, and may include limitations introduced 
5 by the involved protocols, bandwidth restrictions on the involved interfaces, user 
settings, operator settings, etc. 

The bearer limiting factors in the radio access network entity are, for example, 
introduced by the manufacturer of the radio access network entity, and may include 
limitations introduced by the involved protocols, bandwidth restrictions on the involved 

10 interfaces, operator settings, etc. 

The limiting factors in the serving network entity are for example introduced by 
the manufacturer of the serving network entity, are limitations introduced by the 
involved protocols, bandwidth restrictions on the involved interfaces, user settings, 
operator settings, etc. User settings can for example be related to the active calls (never 

15 offer a further call when a call to or from a certain destination is in progress), the 
maximum number of bearers allowed by the user, the services in progress, etc. 
Operator settings can for example be related to a specific subscriber, a group of 
subscribers, a specific network entity, a group of network entities, and the terminal. 
According to one exemplary embodiment of the present invention the involved 

20 entities provide a limit calculation unit with their bearer limit information. This limit 
calculation unit determines the actual limit on the number of available bearers for a 
given set of entities at a given time. This actual limit can then be returned to the 
involved entities and used to invoke multicall capabilities in a manner which prevents 
the afore-described problems. 

25 According to one exemplary embodiment, the limit calculation unit is located in 

the serving network entity. The terminal and the radio access network entity inform the 
limit calculation unit in the serving network entity of their bearer limit information. As 
the limit information of the radio access network entity is not subject to frequent change, 
it can be mirrored in a RNC limits storage unit. This RNC limits storage unit can be 

30 located at the serving network entity and holds the limit information about all of the 
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radio access network entities which are frequently or permanently in contact with a 
particular serving network entity MSC/VLR. Alternatively, the RNC limits storage unit 
can be placed as a stand-alone network entity that holds the limit information of all radio 
network entities. Furthermore, a combined approach of the before mentioned 
5 distributed or centralized schemes could be applied. 



BRIEF DESCRIPTION OF THE DRAWINGS 

10 These and other objects, features and advantages of the present invention will 

become more apparent upon reading from the following detailed description, taken in 
conjunction with the accompanying drawings, wherein: 

FIG. 1 is a block diagram which depicts signalling between an RNC and 
MSC/VLR for informing the MSC/VLR of the RNC's bearer capabilities according to 
15 an exemplary embodiment of the present invention; 

FIG. 2 is a block diagram which depicts signalling associated with the exchange 
of bearer information between user equipment and an MSC/VLR according to an 
exemplary embodiment of the present invention; 

FIG. 3 is a block diagram of selected functional units within user equipment 
20 according to an exemplary embodiment of the present invention; 

FIG. 4 is a flowchart depicting user equipment processing of a user call request 
according to an exemplary embodiment of the present invention; 

FIG. 5 is a block diagram of selected functional units within an MSC/VLR 
according to an exemplary embodiment of the present invention; 
25 FIG. 6 is a flowchart depicting MSC/VLR processing of an incoming call request 

according to an exemplary embodiment of the present invention; 

FIG. 7 is a block diagram which depcits signalling associated with changes to 
bearer capabilities associated with user equipment according to another exemplary 
embodiment of the present invention; 
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FIG. 8 is a block diagram which depicts signalling associated with changes to 
bearer capabilities associated with network equipment according to another exemplary 
embodiment of the present invention and 

FIG. 9 is a signaling/block diagram which depicts bearer capability signalling 
5 associated with relocation of user equipment according to still another exemplary 
embodiment of the present invention. 



10 DETAILED DESCRIPTION 

The various features of the invention will now be described with reference to the 
figures, in which like parts are identified with the same reference characters. In the 
following description, for purposes of explanation and not limitation, specific details are 
set forth, such as particular circuits, circuit components, techniques, etc. in order to 

15 provide a thorough understanding of the present invention. However, it will be apparent 
to one skilled in the art that the present invention may be practiced in other 
embodiments that depart from these specific details. In other instances, detailed 
descriptions of well-known methods, devices, and circuits are omitted so as not to 
obscure the description of the present invention. 

20 Operation in accordance with GSM communication systems is described in, for 

example, European Telecommunication Standard Institute (ETSI) documents ETS 300 
573, ETS 300 574 and ETS 300 578, which are hereby incorporated by reference. 
Therefore, the operation of the GSM system is only described herein to the extent 
necessary for understanding the present invention. Similar standards related documents 

25 are also available for UMTS. Although, the present invention is described in terms of 
exemplary embodiments in a UMTS/GSM system, those skilled in the art will appreciate 
that the present invention may be applicable to other digital communication systems. 

Referring now to Figure 1, as mentioned above, exemplary embodiments of the 
present invention contemplate the exchange of radio bearer limit information as a first 

30 part of a mechanism for handling multicall features in radiocommunication systems 
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where entities may (or may not) be capable of handling multiple bearers simultaneously, 
the number of which may differ as between interacting entities. Therein, in a first step 

101, the radio access network entity (RNC) 102 sends a RanMcCapabilities message to a 
radio network storage entity (RSU) 104 that includes the limit information available 

5 regarding the number of bearers which can be supported, e.g., per terminal, at the RNC 

102. This action is triggered, when, for example, a software update, hardware update, 
a start or restart, or a change of operator settings takes place at the RNC 102. The radio 
network entity storage unit RSU 104 stores the received limit information for later usage 
as described below. As mentioned above, the RSU 104 can be physically located within 

10 MSC/VLR 106 or remotely therefrom but, in any case, has some mechanism for 
transferring information to the entity wherein bearer limit decisions are made. 

Figure 2 depicts part of an exemplary UMTS network including a terminal (UE) 
206, a serving network entity (MSC/VLR 208) and a limit calculation unit (LCU 210) 
that is located, for example, in the MSC/VLR 208. The LCU 210 is, in this example, 

15 collocated together with the RSU 104. For the purposes of this portion of the 

discussion, consider that the RSU 104 has already received the limit information of the 
RNC 102 which is currently serving the UE 206. 

In a first step 201, the terminal UE 206 performs a location updating request 
towards serving network entity MSC/VLR 208. This occurs, for example, during the 

20 initial local registration process, also known as IMSI (International Mobile Subscriber 
Identity) Attach, as well as for any subsequent location updating. In a next step 202, the 
terminal UE 206 sends a UeMcCapabilities message to the limit calculation unit LCU 
210. This message includes the bearer limit information of the terminal UE 206. For 
the case where the terminal performs a location updating that involves change of serving 

25 network entity and for the case of an initial location registration, a Home Location 

Register (HLR, not shown) will provide the limit information as defined by the multicall 
subscription data. The serving network storage unit (MSU) 212 will store the limit 
information received from the Home Location Register. Therefore, for the other cases 
of locating updating, the limit information provided by Home Location Request is 

30 present in radio network entity storage unit RSU 104. Those skilled in the art will 
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appreciate that the transmission of limit information from the UE 206 to the LCU 210 
can occur during processes other than location updating, which is described here as one 
example. In general, limit information can be exchanged at any time before the 
interaction between Multicall and Call Hold or Multicall and Call Waiting should take 
5 place as described in the Background section above. 

The limit calculation unit LCU 210 then calculates the actual limit, i.e., the 
largest number of bearers of any of the three involved entities, taking into account the 
limit information of the serving network entity MSC/VLR, the limit information of the 
involved radio access network entity stored in the serving network storage unit MSU 

10 and the limit information provided by the UE. 

In a next step 203, the limit calculation unit LCU 210 returns the actual limit to 
the terminal UE 206 in a NwMcCapabilities message. The terminal UE 206 stores the 
actual bearer limit in the terminal storage unit USU 214. Furthermore, the actual limit 
is stored in a serving network entity storage unit MSU 212. In step 204, the serving 

15 network entity MSC/VLR 208 confirms the positive outcome of the location updating 
procedure by sending a Location Update Accept message to the terminal UE 206. 

According to another exemplary embodiment of the present invention, the limit 
information of the terminal UE 206 can be transmitted in the Location Updating Request 
message itself, e.g., in an extension of an MS Classmark 2 Information Element. The 

20 MS Classmark 2 Information Element in the Location Updating Request message is well 
known to those person skilled in the art from the 3 GPP TS 24.008 specification, section 
10.5.1.6, version 3.2.1, released January 2000, the disclosure of which is incorporated 
here by reference. The UeMcCapabilities message depicted in Figure 2 can, in this 
exemplary embodiment, then be omitted. The actual limit can also be returned as a 

25 parameter in the Location Update Accept message, in which case the NwMcCapabilities 
message depicted in Figure 2 can be omitted as well. 

As shown in Figure 3, a terminal UE 206 according to exemplary embodiments 
of the present invention comprises a terminal storage unit USU 214, a terminal counter 
UCTR 304, and a terminal control unit UCU 306. The terminal storage unit USU 214 

30 stores the actual limit calculated by the limit calculation unit LCU 210. Alternatively, 



027559-039 



-10- 

the UE 206 may instead calculate the actual limit itself given its knowledge of the UE's 
limits as well as limit information for the network side that is transmitted thereto. 
Regardless of where the actual limit is calculated, the terminal counter UCTR 304 
counts the number of bearers established for the subscriber and the type of the respective 
5 calls. The terminal control unit UCU 306 determines whether the Call Hold service 
should be implicitly invoked at a user request for call set-up, or whether the user request 
for call set-up involves the request for a bearer allocation. For this purpose, the 
terminal control unit UCU 306 processes the information provided by the terminal 
storage unit USU 214 and the information provided by the terminal counter UCTR 304. 

10 The processing by UCU 306 starts, for example, when the user requests a call set-up as 
depicted in the flowchart of Figure 4. 

Therein, the UE processing starts with the user call request 400. In decision step 
401 it is determined whether a bearer is available for the call request. A bearer is 
available if the number of bearers as counted by terminal counter UCTR 304 is lower 

15 than the actual limit as stored in the terminal storage unit USU 214. If the result of 
decision step 401 is that a further bearer is available, then the flow moves to decision 
step 402 where a check is performed as to whether the requested call is a speech call. 

If the result of decision step 402 is that the requested call is not a speech call, 
e.g. , it is for a data connection, then the flow moves to action 405 wherein a new bearer 

20 is requested and the terminal counter UCTR 304 is incremented. If, on the other hand, 
the result of decision step 402 is that the requested call is a speech call, then in decision 
step 403 it is determined whether another speech call is already in progress . If the result 
of decision step 403 is that a speech call is already in progress, then in action 404 the in 
progress speech call is implicitly put on hold. If the result of decision step 403 is that 

25 no speech call is in progress, then in action 405 a new bearer is requested and the 
terminal counter UCTR 306 is incremented. 

If the result of decision step 401 is that no further bearer is available, i.e., if the 
number of bearers as counted by terminal counter UCTR 304 is equal to the actual limit 
as stored in the terminal storage unit USU 214, then in decision step 406 it is 

30 determined whether a speech call is in progress. If the result of decision step 406 is that 
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a call of type speech is in progress, then in action 404 the speech call in progress is put 
implicitly on hold. If, on the other hand, the result of decision 406 is that no speech call 
is in progress, then in action 407 the call request is denied. The decisions made in steps 
402, 403 and 406 can be influenced by user settings, e.g., conference calling, preferred 
5 numbers, etc. 

Referring now to Figure 5, therein a serving network entity MSC/VLR 106, 208 
according to an exemplary embodiment of the present invention includes a serving 
network entity storage unit MSU 212, a serving network entity counter MCTR 502, and 
a serving network entity control unit MCU 504. The serving network entity storage unit 

10 MSU 212 stores the actual limit as calculated by the limit calculation unit LCU 210. 

The serving network entity counter MCTR 502 counts the number of bearers established 
for the subscriber. The serving network entity control unit MCU 504 determines 
whether the Call Waiting service should be invoked when an incoming call is received 
for the user, or whether the incoming call may involve the request for a bearer 

15 allocation. For this purpose, the serving network entity control unit MCU 504 

processes the information provided by the serving network entity storage unit MSU 212 
and the information provided by the a serving network entity counter MCTR 502. The 
processing starts, for example, when an incoming call is received for the user at the 
MSC/VLR 106, 208 as depicted in the flowchart of Figure 6. 

20 Therein, the processing starts with the incoming call at step 600. In decision step 

601, it is determined whether a bearer is available for the call request. A bearer is 
available if the number of bearers as counted by serving mobile entity counter MCTR 
502 is lower than the actual limit as stored in the serving mobile entity storage unit 
MSU 212. If the result of decision 601 is that a bearer is available, then, in decision 

25 step 602, the check is performed to determine whether the requested call is a speech 

call. If the result of decision step 602 is that the requested call is not a speech call, then 
in, action 605, the incoming call set up is performed towards the terminal UE 206. If 
the terminal UE 206 requests allocation of a new bearer for the call, a new bearer is 
allocated and the serving network entity counter MCTR 502 is incremented. 
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If the result of decision 602 is that the requested call is a speech call, then, in 
decision step 603 it is determined whether a speech call is in progress. If the result of 
decision step 603 is that a speech call is in progress, then, in decision step 606, it is 
further determined whether Call Waiting can be invoked for the subscriber. 
5 If the result of decision step 606 is that Call Waiting can be invoked for the 

subscriber, then in action 604 the incoming call set-up is performed towards the terminal 
UE 206, indicating that it is a waiting call. Otherwise, if the result of decision step 606 
is that Call Waiting can not be invoked for the subscriber, then in action 607 the 
incoming call set-up is denied. 

10 If the result of decision step 603 is that no speech call is in progress, then, in 

action 605, the incoming call set up is performed towards the terminal UE 206. If the 
terminal UE 206 requests allocation of a new bearer for the call, a new bearer is 
allocated and the serving network entity counter MCTR 502 is incremented. 

Returning to decision step 601, if the decision there is, instead, that no further 

15 bearer is available, then in decision 606 the check is performed whether Call Waiting 
can be invoked for the subscriber. If the result of decision step 606 is that Call Waiting 
can be invoked for the subscriber, then in action 604 the incoming call set-up is 
performed towards the terminal UE 206, indicating that it is a waiting call. Otherwise, 
if the result of decision step 606 is that Call Waiting can not be invoked for the 

20 subscriber, then in action 607 the incoming call set-up is denied. The decision steps 601 
and 606 can be influenced by user settings and the decision step 601 can be influenced 
by operator settings, e.g., prioritizing calls (such as prioritizing a voice call over a data 
call). 

When a bearer limiting factor in the terminal changes, the terminal UE 206 
25 informs the serving network entity MSC/VLR 106, 208 as depicted in Figure 7. 

Therein, in a first step 701, the terminal UE206 sends a UeMcCapabilities message to 
the limit calculation unit LCU 210. This message includes the current (new) limit 
information of the terminal UE 206. The limit calculation unit LCU 210 calculates the 
new actual limit taking into account the actual limit information stored in the serving 
30 network entity storage unit MSU 212. The new actual limit is then stored in the serving 
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network entity storage unit MSU 212. In a next step 702, the limit calculation unit LCU 
210 returns the new actual limit to the terminal UE 206 in a NwMcCapabilities message. 
The terminal 206 stores the actual limit in the terminal storage unit USU 214. 

When a limiting factor in the serving network entity changes the serving network 
5 entity MSC/VLR 106, 208 informs the terminal UE 206 as depicted in Figure 8. 
Therein, in a first step, the limit calculation unit LCU 210 calculates the new actual 
limit taking into account the actual limit information as stored in the serving network 
entity storage unit MSU 212. The new actual limit is then stored in a serving network 
entity storage unit MSU 212. In a next step 802, the limit calculation unit LCU 210 

10 returns the actual limit to the terminal UE 206 in a NwMcCapabilities message. The 
terminal stores the actual limit in the terminal storage unit USU 214. 

When a Relocation procedure takes place, i.e., a handoff which involves 
switching RNCs, the new RNC's bearer limiting factors may not be known to the 
serving network entity MSC/VLR 106, 208. The limiting factors of the new radio 

15 access network entity RNC are then sent to the serving network entity MSC/VLR 106, 
208 as depicted in Figure 9. Therein, at step 901, the current radio access network 
entity RNC1 (900) requests a relocation procedure from the serving network entity 
MSC/VLR 106, 208 by sending a Relocation Required message. This message includes 
the information that the relocation is to be performed towards radio access network 

20 entity RNC2 (908). 

In a next step 902, the serving network entity MSC/VLR 106, 208, confirms the 
request of the radio access network entity RNC1 (900). Then, at step 903, the serving 
network entity MSC/VLR 106, 208 requests the relocation from RNC2 908 by sending 
the Relocation Request message. At step 904, the radio access network entity RNC2 

25 908 sends its own bearer limit information in a RanMcCapabilities message to the radio 
network entity storage unit RSU 104. 

Then, at step 905, the radio access network entity RNC2 908 ends the relocation 
procedure by sending the Relocation Request Ack message to the serving network entity 
MSC/VLR 106, 208. The limit calculation unit LCU 210 calculates (step 906) the new 

30 actual limit taking into account the new limit information in the radio network entity 
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storage unit RSU 104, the actual limit stored in the serving network storage unit MSU 
and the limit associated with the UE. The new actual limit is stored in the serving 
network storage unit MSU 212. The limit calculation unit LCU 210 returns the actual 
limit to the terminal UE 206 in a NwMcCapabilities message. The terminal stores the 
5 actual limit in the terminal storage unit USU 214. 

The functions described herein may, as will be apparent to those skilled in the 
art, be performed, at least in part, by way of software implemented on a computer- 
readable medium, to perform the afore-described techniques. The computer-readable 
medium may reside, for example, in any of the entities described herein and may also be 
10 found on portable computer-readable medium for the purpose of loading such software 
onto these entities. 

Although the invention has been described in detail with reference only to a few 
exemplary embodiments, those skilled in the art will appreciate that various 
modifications can be made without departing from the invention. For example, the 

15 above-mentioned counters, i.e. , the terminal counter UCTR and the serving network 
entity counter MCTR, may not be explicitly implemented as counters, but can also be 
derived from other data already available at the terminal UE and, respectively, the 
serving network entity MSC/VLR. 

The terminal control unit UCU and the serving network entity control unit MCU 

20 and the limit calculation unit LCU can be implemented for example as integrated circuits 
or software modules. The limit calculation unit LCU may be implemented in any of the 
involved system entities or may be implemented as a stand-alone unit. Furthermore, 
each of the involved system entities may host a limit calculation unit LCU of its own for 
local computation of the actual limit. In such a case, instead of the actual limit, the 

25 limiting information is exchanged between the involved system entities. 

The exchange of limit information may be initiated by one of the system entities 
by requiring the limit information from the other involved system entities. 
Alternatively, one of the system entities may initiate the exchange of limit information 
by sending its limit information to at least one of the involved system entities. 
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Accordingly, the invention is defined only by the following claims which are intended to 
embrace all equivalents thereof. 



